Date: Fri, 27 May 94 04:30:19 PDT From: Ham-Digital Mailing List and Newsgroup Errors-To: Ham-Digital-Errors@UCSD.Edu Reply-To: Ham-Digital@UCSD.Edu Precedence: Bulk Subject: Ham-Digital Digest V94 #165 To: Ham-Digital Ham-Digital Digest Fri, 27 May 94 Volume 94 : Issue 165 Today's Topics: DSP questions (3 msgs) NOS with the Baycom Modem Pin-out for Tiny-2/Micropower-2 to Radio Shack HTX 202/ICOM 2AT? Probs with Micropower-2 Quiet computers VHF Packet net questions Send Replies or notes for publication to: Send subscription requests to: Problems you can't solve otherwise to brian@ucsd.edu. Archives of past issues of the Ham-Digital Digest are available (by FTP only) from UCSD.Edu in directory "mailarchives/ham-digital". We trust that readers are intelligent enough to realize that all text herein consists of personal comments and does not represent the official policies or positions of any party. Your mileage may vary. So there. ---------------------------------------------------------------------- Date: 26 May 94 19:49:35 GMT From: news-mail-gateway@ucsd.edu Subject: DSP questions To: ham-digital@ucsd.edu Is anyone out there aware of any experiments done in the use of DSP to produce simulated spatial displacement of audio tones as a function of their frequency? What I have in mind is being able to spread a pile-up by having the lower-frequency tones appear to be on the right and the higher ones on the left, in an experiment to see whether that helps pick out individual signals. Could such a thing be implemented using an ordinary sound-card with stereo outputs as the interface? 73, Pete n4zr@netcom.com NOTE: New Address ------------------------------ Date: 26 May 1994 21:16:54 GMT From: ihnp4.ucsd.edu!swrinde!gatech!news-feed-1.peachnet.edu!news.duke.edu!eff!news.kei.com!ssd.intel.com!chnews!cmoore@network.ucsd.edu Subject: DSP questions To: ham-digital@ucsd.edu Peter G. Smith (n4zr@netcom.COM) wrote: : Is anyone out there aware of any experiments done in the use of DSP to : produce simulated spatial displacement of audio tones as a function of : their frequency? 73, Pete n4zr@netcom.com Just such an analog design appeared in one of the amateur pubs a couple of years ago. It was a low-pass filter to the left ear and a high-pass filter to the right ear. It could easily be done with a soundcard. 73, KG7BK, CecilMoore@Delphi.com ------------------------------ Date: 27 May 1994 01:52:47 GMT From: ihnp4.ucsd.edu!agate!darkstar.UCSC.EDU!news.hal.COM!olivea!inews.intel.com!mipos2!dcurtis@network.ucsd.edu Subject: DSP questions To: ham-digital@ucsd.edu In article <2s33k6$mdk@chnews.intel.com> cmoore@ilx018.intel.com (Cecil A. Moore -FT-~) writes: >Peter G. Smith (n4zr@netcom.COM) wrote: >: Is anyone out there aware of any experiments done in the use of DSP to >: produce simulated spatial displacement of audio tones as a function of >: their frequency? 73, Pete n4zr@netcom.com > >Just such an analog design appeared in one of the amateur pubs a couple >of years ago. It was a low-pass filter to the left ear and a high-pass >filter to the right ear. It could easily be done with a soundcard. > >73, KG7BK, CecilMoore@Delphi.com > Ah, but to get spacial placement, what you want to do is alter the phase delay to each ear and keep the amplitude flat. The stereo effect is a function of phase, not amplitude. Each channel should be an all-pass function, with symetrically opposite group delay curves. Several years ago there was an analog circuit published in, I believe, Ham Radio that did just that. Some time in the early 80's, like maybe '83, there was an issue of either IEEE Spectrum or maybe the Proceedings of the IEEE that was an anniversary issue of some kind. The contents were seminal papers in several areas, one of which was a great paper on stereo audio and how it worked. This was when "Stereo Hi-Fi" was new and nifty stuff. (BTW, the other papers in the issue are equally nifty.) Anyway, go read the stereo paper and the silliness of using amplitude to get spatial placement will be quite apparent. The DSP version should be pretty simple -- Do an all-pass with linear group delay on one channel, and simply delay the other channel to place middle tones in the middle of space. 73, Dave NG0X dcurtis@mipos2.intel.com ------------------------------ Date: Fri, 27 May 94 02:40:39 GMT From: ihnp4.ucsd.edu!library.ucla.edu!csulb.edu!csus.edu!netcom.com!netcomsv!skyld!jangus@network.ucsd.edu Subject: NOS with the Baycom Modem To: ham-digital@ucsd.edu Jeff Please forward this to the appropriate newsgroup/individual TCP/IP WITH NO TNC By: Mike Hooper, KF6PU TNCs run in the kissmode and SCC cards such as the DRSI PCPA have long been the staple of most TCP/IPers running NOS and Net versions of the KA9Q Internet Suite of Protocols. There is a much less expensive and more elegant solution for a 1200 baud hardware interface. "Baycom" style modems have enjoyed international popularity for some time now among those running packet software that employs the "software tnc" approach. Baycom, PMP, and Eskay Packet (SP) V6.10 with the TFPCX driver are very popular. Most Baycom style modems are designed around either the AMD 7910 "World Chip" IC , Texas Instruments TCM 3105, or the EXAR 2206/2211 pair. Most commercial TNCs use these chips for the modem section. For example, the AEA PK-88 uses the AMD 7910, The Kantronics KAM and KPC-4 use the TCM 3105 for VHF-UHF ports and the MFJ 1270/1274 use the EXAR pair. Few external parts are required for these modems and they are easy to construct. The TCM 3105 modem can be built for under $25.00 and can be built so small as to fit into a DB25 shell. Thanks to the efforts of Pawel Jalocha, SP9VRC (SP9VRC@SP9ZDN.POL.EU) (jalocha@chopin.ifj.edu.pl) a packet driver conforming (to a sufficient extent) to the "FTP packet driver specification" has been developed that serves as an interface between application software (e.g. KA9Q NOS) and a modem connected to the RS232 port (e.g. Baycom modem). This driver along with documentation and accessory files have been distributed in this country under the filename "AX25DRV.ZIP" . Be sure to use the January 4, 1993 version as prior releases have bugs. Jawel's packet driver enables the use of unsquelched audio as the driver is able to deliver "channel busy" status by analyzing incoming data. The driver is loaded into memory before NOS is run. The utility "TERMIN.COM" is used to remove the driver from memory when one exits from NOS. Below is a batch file that sets up the driver for use on COM2 with NOS : @echo off c: cd\net ax25 -b1200 -B2f8 -I3p -cd -h350 nos.exe termin.com cls The switches invoked with ax25.com specify: 1200 baud, COM2, IRQ priority (given to IRQ 3 in this example), carrier detect option, and txdelay. Slottime and persist default to 100 msec. and 64 but are adjustable with the -s and -p switches. The software interrupt defaults to 0x60 but is adjustable from 60 through 63 with the -i switch. Carrier detect threshold and TXtail are also adjustable with the -T and -t switches. A switch need not be specified if the default value is used. Within AUTOEXEC.NOS is the following attach statement (your version of NOS must be compiled with the attach packet hardware interface option): attach packet 0x60 144 5 256 I have been using this driver with both the WG7J and KB7YW versions of NOS for several weeks. My system utilizes three hardware interfaces two of which are handled by a DRSI card. During this period I have had the opportunity to use a KAM (v6.0), PK-88, and a PK-232 with the TAPR DCD mod and in no case have I found these superior to a TCM 3105 modem used with Jawel's ax25 driver. The driver does not work well on an XT clone. My computer is a 386-33 SX using a pair of 16550 AFNs. I find it useful to reset the computer before running NOS to "clear" the comports. Work is currently in progress on adapting the G3RUH 9600 modem for use with the AX.25 driver. Potential problems concerning interrupt latency issues may complicate matters. If success is achieved it would substantially reduce the cost of running TCP/IP at 9600 baud. -73- kf6pu@wb6ymh.#soca.usa mhooper@netcom.com 73 es GE from Jeff ---------------- Amateur: WA6FWI@WA6FWI.#SOCA.CA.USA.NOAM | "You have a flair for adding Internet: jangus@skyld.grendel.com | a fanciful dimension to any US Mail: PO Box 4425 Carson, CA 90749 | story." Phone: 1 (310) 324-6080 | Peking Noodle Co. Hate "Green Card Lottery"? Want to help curb ignorant crossposting on Usenet? E-mail ckeroack@hamp.hampshire.edu for more information, or read news.groups. ------------------------------ Date: 26 May 1994 15:28:23 GMT From: ihnp4.ucsd.edu!usc!math.ohio-state.edu!hobbes.physics.uiowa.edu!news.uiowa.edu!icaen!drenze@network.ucsd.edu Subject: Pin-out for Tiny-2/Micropower-2 to Radio Shack HTX 202/ICOM 2AT? To: ham-digital@ucsd.edu Will somebody who's hooked their PacComm Tiny-2 OR Micropower-2 TNC to either a Radio SHack HTX-202 or another ICOM 2AT-compatible HT please e-mail me the wiring configuration? I've got a Micropower-2 but the company is currently out of manuals so I don't know how to get it wired. -- __ /| | Doug Renze, N0YVW | \'o.O' | +1 319 339 7814 | Amateur Radio: =(___)= | drenze@icaen.uiowa.edu | Bringing the World Together U | | ------------------------------ Date: 26 May 1994 15:17:00 GMT From: ihnp4.ucsd.edu!library.ucla.edu!europa.eng.gtefsd.com!howland.reston.ans.net!math.ohio-state.edu!hobbes.physics.uiowa.edu!news.uiowa.edu!icaen!drenze@network.ucsd.edu Subject: Probs with Micropower-2 To: ham-digital@ucsd.edu Ergle. I'm having a prob that I hope really isn't one... I've got a Micropower-2 TNC hooked up to my computer, but don't have the radio hooked up yet (haven't got the cables and can't quite figure out how to wire it to the HTX-202/ICOM 2AT config). Well, I decided to switch it on today to play around with the commands and...nothing. I've done this before and gotten a nice startup screen followed by the "cmd>" prompt, but today I got absolutely zilch, though it does echo characters and character returns back to the screen so I don't really think anything's fried. Am I in some sort of weird mode somehow, and how can I get it back out of it? Or am I f***ed? -- __ /| | Doug Renze, N0YVW | \'o.O' | +1 319 339 7814 | Amateur Radio: =(___)= | drenze@icaen.uiowa.edu | Bringing the World Together U | | ------------------------------ Date: Thu, 26 May 1994 13:30:05 GMT From: ihnp4.ucsd.edu!library.ucla.edu!csulb.edu!csus.edu!netcom.com!greg@network.ucsd.edu Subject: Quiet computers To: ham-digital@ucsd.edu Here's a different subject... What specific brands/models of PCs have folks found to be particularly good or bad with regard to RF hash generated, and suseptability to RF fields? I'll start: my Compudyne 38625SXL (Twinhead) notebook is pretty good as far as generating noise, below 10.15 Mhz. On 20 meters, and up, it's pretty much of a disaster, growing worse as the frequency increases, even when run on battery power and equipped with split ferrites on all external cables. The LCD display seems to be part of the problem. On the plus side, it tolerates fields which are equal or greater to what the PK232 can take. Greg ------------------------------ Date: 26 May 1994 21:53:10 GMT From: ihnp4.ucsd.edu!swrinde!gatech!nntp.msstate.edu!Ra.MsState.Edu!cll4@network.ucsd.edu Subject: VHF Packet net questions To: ham-digital@ucsd.edu We are currently trying to get a VHF packet net started to increase the general use of packet in our area. We have been having trouble deciding what format to use to get everyone together. We have considered an unproto via 2 area digis, connecting to a net/rom (I think) node and using a talk feature (which sends each user's packet to everyone individually), and are out of ideas of a smooth way to accomplish this. There will be some people who will have to digipeat to get into our area. Any and all ideas will be welcome, and if anyone has such a beast currently running, I would love to hear from you. Thanks in advance, Craig -- --------------------------------------------------------------------------- Craig Lindsey - KC5AUG | My politics are simple: Always go right. If Internet: cll4@ra.msstate.edu| you go left, you can never go right, and if Bitnet: cll4@msstate.bitnet| you go right, you never go wrong. -Grizzard Packet: kc5aug@w5vzf.ms.usa.noam ------------------------------ Date: Thu, 26 May 1994 14:47:25 GMT From: ihnp4.ucsd.edu!pacbell.com!amdahl!juts.ccc.amdahl.com!szb50@network.ucsd.edu To: ham-digital@ucsd.edu References , <2s0hvr$mko@u.cc.utah.edu>, Reply-To : szb50@JUTS.ccc.amdahl.com (Sid Boyce) Subject : Re: >9600 bps packet (was: Re: 9600 bps radio modems) Anonymous ftp col.hp.com /hamradio/packet/n6gn/uwavelink(multi megabaud) ftp.ucsd.edu has stuff .... tapr9600.mod and 96man.txt if you are looking for 9600 baud info. 73 Sid Boyce ... G3VBV .... Amdahl(UK) ... G3VBV@GB7BHM.#29.GBR.EU ------------------------------ Date: Thu, 26 May 1994 21:54:03 GMT From: ncrgw2.ncr.com!ncrhub2!ranger!cn2935.DaytonOH.NCR.COM!jra@uunet.uu.net To: ham-digital@ucsd.edu References <548.18.uupcb@totrbbs.atl.ga.us>, , <2s0hvr$mko@u.cc.utah.edu> Subject : Re: >9600 bps packet (was: Re: 9600 bps radio modems) In article <2s0hvr$mko@u.cc.utah.edu> val@cs.weber.edu (Val Kartchner) writes: >In article rdonnell@eskimo.com (Bob Donnell) writes: >>I'm suprised John didn't mention it - the new TAPR NETSIG mailing list is >>heavily involved in discussing 9600 (and faster) modem/radio issues. >How do I read this mailing list? Is it a packet-only mailing list, or >is it available to Internet users? ObPlug: The TAPR NetSIG mailing list is devoted to discussion of amateur packet radio networking issues. It's not limited to hardware discussions, though there's plenty of that going on right now. To subsrcribe, send a message to listserv@tcet.unt.edu with "join netsig" in the body. To submit messages, send to netsig@tcet.unt.edu. Note: the list has been very busier -- busier than we had ever hoped -- and as a result we recently had to change homes, and there have been a few bugs in the system. Please bear with us. John AG9V jra@lawdept.daytonOH.ncr.com PS -- No, I don't know much about the NCR Wavelan stuff, despite my address. I wish I did, but I've never been able to get my hands on any surplus units. ------------------------------ Date: Thu, 26 May 1994 21:46:29 GMT From: ncrgw2.ncr.com!ncrhub2!ranger!cn2935.DaytonOH.NCR.COM!jra@uunet.uu.net To: ham-digital@ucsd.edu References , <548.18.uupcb@totrbbs.atl.ga.us>, rh Subject : Re: 9600 bps radio modems In article rdonnell@eskimo.com (Bob Donnell) writes: >Also, as a side note, when we've done testing here on link reliability we >usually are using the 'ping' feature of tcp/ip and NOS to do the testing. >We run 'datagram' (unconnected) mode and usually use 200-400 byte packets. >I have noticed that with two analog modems (TAPR on one end, PK-900/PK-96/ >TAPR/G3RUH on the other) that the best ping response I can get is about 95% >through our TAPR bit-regen modem equipped 2M repeater. This is over about a >45 mile line-of-site path. Switching to a DSP-2232 will improve the ping >return rate to about 98-99%. Kudoes to N4HY. Note that due to atmospherics >(ducting, etc) and the fact that the repeater is at about 5000 feet we have >times when the path to the repeater is poor to unusable, too. This is part >of why our next generation of repeaters are at low altitude sites, mostly >cell sites. Here's another data point: we do our testing on the 19.2 repeater the same way, via ping, usually with a 256 byte packet and 3 or 4 second interval. We also see ping hit rates of about 95% at best, 85% or so at worst, through the repeater (with reasonable but not pile-driver paths, and some other activity on the system). In bench tests, we get up to 98-99 percent. The non-returns generally are about evenly spaced, with occasional clusters of two or three drops in a row. Even over very long tests, we almost never see a run of more than 100 pings without a drop. This is using the D4-10 as an RF modem, directly driven by modem disconnect header or PI card. No scrambler. And, unfortunately, no bit regen (yet). I'm very interested in seeing whether adding bit regen is going to improve error rates generally, or only help on marginal signals. We're hoping to add a regen later this summer (once I can get a TAPR 9600 modem kit to butcher). John AG9V jra@lawdept.daytonOH.ncr.com ------------------------------ Date: 26 May 1994 19:28:36 GMT From: ihnp4.ucsd.edu!swrinde!gatech!howland.reston.ans.net!spool.mu.edu!torn!hermes.acs.ryerson.ca!ee.ryerson.ca!jeff@network.ucsd.edu To: ham-digital@ucsd.edu References <2q8erk$qdc@hermes.acs.ryerson.ca>, <1994May23.061932.641@beacons.cts.com>, Subject : Re: PacketRadio forLinux with Baycom ?? Daniel T Senie (dts@world.std.com) wrote: : In article <1994May23.061932.641@beacons.cts.com> kevin@beacons.cts.com (Kevin Sanders) writes: : >In article <2q8erk$qdc@hermes.acs.ryerson.ca> jeff@ee.ryerson.ca (Donald Jeff Dionne) writes: : >> : >>said that, however, there is a driver for Linux that does audio over the : >>pc speaker using a timer and some sort of PWM, and it works unless the : >>machine is busy with disk I/O or the like..... If you don't mind packet : >>loss when the machine is busy, and the machine comming to a halt when : >>packet is going on (as it does with the pc speaker), then perhaps I'm : >>wrong and it's worth a try. : > : >I experimented with a similar project; I wrote a driver which speeds up : >the system clock and samples one of those AEA fax interface units, to : >try to get HF fax running under Linux. I found that the IDE disk driver : >(at least for Linux 0.99.10 or so) disabled interrupts for long enough : >to skew my picture by 5-10% of the width each time a sync() occured :-( : > : >I did not notice any other delays besides the IDE disk. I now have : >a SCSI-based system and it may not exhibit this problem. I also heard : >that the Linux IDE driver has been improved lately and does not disable : >interrupts for as long as it used to. : Actually, many of the SCSI adapters, such as the 1542 from Adaptec, are : BUS MASTER devices. This means that the main CPU cannot get on the bus : to service interrupts at all during some periods. Bus mastering is a : desirable way to improve performance for DMA on disk controllers. Expect : to see lots more bust mastering on the newer bus achitectures. No, I have a 1542 in my Linux box, and it does not steal enough cycles to cause a problem with anything :-) : > : >Bottom line is, you must use the timer interrupt for polling as it is : >the highest priority; and also you had better have as good (or better) : >an understanding of the behavior of every driver, wrt locking out : >interrupts, as the people who wrote them. It's probably safest to : >determine this empirically, by cranking up the tick speed and counting : >the ticks for a few hours. Beat on the system as hard as you can during : >this time, and see if you missed any ticks (by checking against a : >real clock). You should be able to nail down the maximum tick rate : >permissible and then decide if this is fast enough sampling for your : >application. Yes. With a 386dx33, you can get 20k interrupts per second. That's an order of magnitude more than needed. On a 486dx2-66, 70k. On even a 386dx33, the impact on system performance would be acceptable, perhaps even go un-noticed! Seems I was wrong... this is do-able. : Bottom line is, a PC's main processor makes a terrible SCC controller. : the BAYCOM and PMP approaches are neat little hacks that really can : only work when you're talking about a DOS based machine that can run : without any preemption. Windows, Unix, Linux, OS/2, and most operating : systems have preemptive scheduling. Sure you can tweak them to handle : the timing needed for a $50 BAYCOM modem, though you run the risk of : having to spend considerably more on enough computer horsepower to : hit the timing windows, and enough of your time to make it non-cost : effective. You are right, of course. It's not a good solution, but cost effective? I think so. No, there's no profit to be make, but once the code is written, packet under Linux is much more affordable for those that don't have (or want to spend) the extra for a real TNC. : What I find odd, is that spending another $50 to get to $100 and buy a : real TNC, that can handle the synchronous communications of the packets : on the air, handle the HDLC framing, etc. is MUCH simpler than trying : to hack a multi-threaded or multi-processing OS into being able to : handle a BAYCOM modem. Sometimes the hardware solution is cheaper... It's only cheaper the first time. If it could be made to work, BAYCOM style modems for Linux would open up packet to new users for far less than any other solution. : > : Dan N1JEB : -- : --------------------------------------------------------------- : Daniel Senie Internet: dts@world.std.com : Daniel Senie Consulting n1jeb@world.std.com : 508-779-0439 Compuserve: 74176,1347 ------------------------------ Date: Thu, 26 May 1994 09:49:03 GMT From: ihnp4.ucsd.edu!swrinde!pipex!uknet!icsbelf!mark@network.ucsd.edu To: ham-digital@ucsd.edu References <548.18.uupcb@totrbbs.atl.ga.us>, , <2s0hvr$mko@u.cc.utah.edu> Subject : Re: >9600 bps packet (was: Re: 9600 bps radio modems) Is there an ftp archive or, even better, a WWW server for information on high speed packet? Perhaps someone would like to run a server at their site? We'll be doing some 9600 links here in GI soon, and I'm hoping to get some info to help me get things going. -mark -- Mark Willis Internet: mark@icsbelf.co.uk ICS Computing Group Ltd. Packet: GI0PEZ@GB7TED.#63.GBR.EU Belfast AmprNet: 44.131.15.3 Northern Ireland CompuServe: 100317,3025 ------------------------------ End of Ham-Digital Digest V94 #165 ******************************